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PREFACE 



The Usage Accounting Utility was developed by Control 
Data Corporation to provide a mechanism by which to bill 
application products users on a usage basis, rather than 
by a flat, monthly rental charge. It is intended for use in 
the user's environment on any of the following systems 
running under the NOS/BE 1. or NOS 1.0 operating 
system. 

• CONTROL DATA® 6000 Computer System; 

• CONTROL DATA® CYBEE 70 Computer System, 
Models 71, 72, 73, 74; and 

• CONTROL DATA® CYBER 170 Computer System, 
Models 171, 172, 173, 174, and 175. 

Other Control Data publications which may prove helpful 
to the user include: 



Title 
NOS/BE Reference Manual 

NOS 1. Reference Manual, Volume 1 

NOS 1. Reference Manual, Volume 2 

FORTRAN Extended 4 Reference Manual 

COMPASS 8 Reference Manual 

COBOL 4 Reference Manual 

UPDATE Reference Manual 

CYBER Record Manager Version 1 
Reference Manual 

Application Installation Handbook 
NOTE 



Publication 
Number 
60493800 

60435400 

60445300 

60497800 

60492600 

60384100 

60449400 

60495700 

76071100 



This product is intended for use only as described 
in this document. Control Data cannot be respon- 
sible for the proper functioning of undescribed 
features or undefined parameters. 
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INTRODUCTION 



The Usage Accounting Utility Is a two-part package con- 
sisting of a usage data reduction and reporting utility pro- 
gram (RANDR) and a set of application Interface subrou- 
tines (ACOUNTX) which records applications usage. 

The RANDR program is a multipurpose, control card 
callable program which performs the following functions: 

• Maintains the product file data base, 

• Generates usage detail reports, 

• Generates a summary usage report of all product 
usage since the last billing run, 

• Generates a billing report of all product usage 
since the last billing run, and 

• Generates system status reports. 

Because RANDR can be employed for user application 
programs as well as Control Data application products, 
reports are generated by individual vendor codes with 
user reports separate from Control Data product reports. 

ACOUNTX is a set of subroutines specifically created to 
provide the interface between the application, the product 
usage detail file, and the other usage recording media. 
ACOUNTX is callable only from programs (that is, it is 
not control card callable) meeting the interface require- 
ments specified in this document. Its main function is to 
record data concerning the applications usage on the detail 
file stor^e medium and log that usage on the user and 
system dayfiles. 



STEPS IN USAGE ACCOUNTING 
PROCESSING 



RANDR PROGRAM PROCESSING 

The processing steps involved in the RANDR program 
depend upon the particular type of run: whether it is an 
update, summary, or billing run. 

An update run updates the product name file by inserting 
or deleting product name entries, name/address infor- 
mation and/or various usage protection parameters, de- 
pending upon the input cards to RANDR. 



Billing runs may be made on any day of a given month and 
cover the period from the first through the last day of the 
preceding month. Thus, a billing run made on 20 January 
covers the period of 1 December through 31 December. 
Subsequent billing runs generate data from the end of the 
period covered by the previous billing run through the 
final day of the month to be reported. For example, if the 
last billing run was made on 20 January (which covered 
the period of 1 December through 31 December), a billing 
run on 8 February would report usage from 1 January 
through 31 January. 

The reporting period of summary runs differs from that 
of billing runs in that usage is reported from the end of 
the period covered by the previous billing period throi:^h 
the current date and time. In contrast to the preceding 
billing example, if the previous billing run was on 20 
January, a summary run on 8 February would report usage 
from 1 January through the current time on 8 February. 

A billing run made on a date less than one full month past 
the last billing can be used as an interim billing in order 
to reduce the usage detail file size on mass storage. It 
would cover from the end of the previous billing run to the 
current date and time. For example, if the last billing 
run was made on 20 January (which covered the period of 
1 December through 31 December), a billing run on 27 
January would report usage from 1 January through the 
current time on 27 January, A subsequent run on 8 
February would report usage for 27 January through 31 
January, but would show the invoice amoimt for 1 January 
through 31 January. 

Reports from billing runs for Control Data usage priced 
products must, in some cases, be retained for possible 
request by Control Data and, in other cases, be forwarded 
to the Control Data office specified on the reports. Usage 
detail Information and interim summary usage information 
must be retained as supporting information to the monthly 
summary usage report which is sent to Control Data. 
Appropriate instructions appear on all such reports. 
Reports from summary runs are informational and for the 
user's utilization. 

Determination of the type of run is made by the data deck 
input to the system. Data deck input may define an update, 
summary, or billing run. Figures 1-1 and 1-2 illustrate 
the steps in RANDR processing. 



Billing and summary runs are identical excluding two 
exceptions : the detail record file is not purged and rebuilt 
for a summary run as it is for a billing run, and the re- 
porting period and data generated are different for each 
run. 
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Figure 1-1. EANDR General Processing Chart for Summary or Billing Runs 
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Figure 1-2, RANDR General Processing Chart for an Update Run 



'Under NOS operation, whenever the EANDR card is used, the ACCOUNT card must also be used with usernum=ACXLIB. 
The format is: ACCOUNT, ACXLIB, passwrd, family. 
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ACOUNTX PROCESSING 

Application products leased by Control Data Corporation on 
a us^e basis interface with the usage accumulator portion 
of the Usage Accounting Utility (ACOUNTX). The primary 
function of ACOUNTX is to record the actual usage of 
leased applications, ACOUNTX is stimulated by calls to 
it by the application with a parameter string defining the 
operation to be performed and a number of values to be 
used in logging the transaction. Figure 1-3 shows the 
general flow of ACOUNTX. 

ACOUNTX is program callable from COMPASS, COBOL 
or FORTRAN Extended programs employing the following 
call-by-name convention: 



COBOL 4, FORTRAN Extended 4 (FTN 4) and COMPASS 
meet the following calling sequences. 

The following form applies to calling ACOUNTX under 
COBOL: 

ENTER FORTRAN-X ACOUNTX USING PI, P2 , P3 , P't, P5, 
P6, P7, P8 

The following form applies to calling ACOUNTX under FTN: 

CALL ACOUNTX (PI, P2, P3, P**, P5, P6, P7, P8) 

The following form applies to calling ACOUNTX under 
COMPASS: 

TRWD VFD ita/SHENTER, 18/ENTER 



Name 



Meaning 



SAl Address of the argument list. 

+RJ Subprogram name. 

-VFD 12/line number, 18/trace word address 

where: 

line number = source line number of the state- 
ment containing the reference, 
and 

trace word address = address of trace word for the 
calling routine. 

The argument list consists of consecutive words of the 
form: 



ENTER 



EQ 



A+1S17 



ENTRY POINT 



Name 



Meaning 



VFD 60/address of argument 



BSSZ 



APPLI- 
CATION 





SAl 


PARMADR 






+ 


RJ 


ACOUNTX 


CALL ACCOUNTING 




~ 


VFD 


12/*,18/TRWD 






PARMADR 


VFD 


60/P1 


ADDRESS OF FUNCTION 






VFD 


60/P2 


ADDRESS OF PARAMETER 


2 




VFD 


60/P3 


ADDRESS OF PARAMETER 


3 




VFD 


(>0/?k 


ADDRESS OF PARAMETER 


k 




VFD 


60/P5 


ADDRESS OF PARAMETER 


5 




VFD 


60/P6 


ADDRESS OF PARAMETER 


.6 




VFD 


60/P7 


ADDRESS OF PARAMETER 


7 




VFD 


60/P8 


ADDRESS OF PARAMETER 


8 




BSSZ 


1 


ZERO TERMINATOR 




PI 


VFD 


60/5LSTAUU 


START FUNCTION 




P2 


VFD 


60/1 OH SWNAME 


SOFTWARE NAME 




P3 


VFD 


60/itLSWCD 


SOFTWARE CODE 




P4 


CON 


250 


RATE 




P5 


CON 





SURCHARGE 




P6 


VFD 


60/4H 


ITEM CODE DESIGNATOR 




P7 


CON 





AUU LIMIT 




P8 


VFD 


60/2LCD 


VENDOR CODE 





Section 3 contains a complete description of ACOUNTX 
functions and parameters. 
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PRODUCT 
-^ USAGE 



Figure 1-3. ACOUNTX General Process Chart 
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RANDR OPERATION 



The usage data reduction and reporting utility program 
(RANDK) is a bi-functional program within the Usage 
Accounting Utility. It exists to maintain the product file 
and produce the usage reports. The specific function to 
be performed is determined by the data input to RANDR. 
Figure 2-1 shows a sample deck structure used to call 
RANDR. The program operates on two files: the usage 
detail file and the product file. The usage detail file con- 
tains information relating to all runs that are usage priced, 
while the product file contains back-up information regard-^ 
ing vendor, user, and billing period totals for each appli- 
cation product. 



tion of the permanent file system. Whenever it becomes 
necessary to create the product file, operator permission 
is requested prior to file initialization by the following 
message: 

PAUSE PRODUCT FILE 

LOAD PRODUCT FILE - GO OR DROP 

An operator response of GO causes a new product name file 
to be created. If the operator enters DROP the job is 
dropped. 

NOTE 



TYPES OF RUNS 



If the product file exists on a dump tape, the file 
should be restored by a load from the most recent 
dump tape rather than by an update creation run. 



RANDR processes three types of user requests: update, 
billing, or summary as specified on the parameter cards In 
the input data deck (see Data Deck subsection in section 2. ) 



UPDATE RUNS 

Update runs create the product file and perform changes 
on the entries once the file has been created. Update runs 
for the purpose of creation are necessary only at the time 
of initial installation unless the file is lost through destruc- 



In addition to creating and maintaining the product file, an 
update run is the only means of establishing the usage de- 
tail file. The update phase of RANDR checks for the 
existence of the usage detail file. If the file is present the 
update continues; if, however, the file is nonexistent, the 
following message is displayed on the console: 

PAUSE NO DETAIL FILE 

LOAD DETAIL FILE - GO OR DROP 

An operator response of GO causes the usage detail file to 
be initialized. A DROP response from the operator causes 
the job to be dropped. 
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Figure 2-1. Sample Deck to Call RANDR 



'Under NOS operation whenever the RANDR card is used the ACCOUNT card must also be used with usernum=ACXLIB. 
The format is: ACCOUNT, ACXLIB, passwrd, family. 
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NOTE 



BILLING RUNS 



li the usage detail file exists on a dump tape, the 
file should be restored by a load from the most 
recent dump tape rather than by an update creation 
run. 

After the initial creation of the product file, update runs 
are used to modify existing information within the file. 
This is accomplished by the information on the input data 
deck. User supplied information Input to RANDR update 
via the input data deck consists of the following: 

• Number of copies of reports to be generated; 

• Control Data Corporation name, address, and 
contact; 

• User name, address, and contact; 

• Vendor codes, software codes, and product names 
for each product; and 

• Parameters for usage and reporting protection. 

Input transactions are sorted by vendor, software code, 
product, and card sequence number. The update report 
shows the processing result of every transaction. Informa- 
tion and run termination messages are shown when 
necessary. 



Billii^ runs extract the detail usage records from the 
usage detail file, update the six- month AUU totals and the 
accumulated AUU totals for each product in the product file, 
and produce the usage detail report, the usage summary 
report (billing report), and the system status report. A 
billing run is Indicated by specifying BILLING on the para- 
meter card (see the Parameter Card subsection in section 
2). 

Billing runs also perform a clean-up function on the usage 
detail file by eliminating already totaled detail records. 
Detail information representing activity subsequent to the 
billing period is not extracted. 

Billing runs can be made at anjrtlme, but a full ^onth con- 
stitutes a billing period. Billing runs made at less than 
full- month Intervals also produce a usage detail report, a 
usage summary report (Interim), and a system status 
report. 

In all billing run cases, the detail reports for Control Data 
products are to be retained. Usage summary reports are, 
depending upon the elapsed time since the last billing run, 
to be forwarded to Control Data. Appropriate Instructions 
are generated for each such report. System status reports, 
and other reports without specific Instructions, are 
Informational. 



Because of the importance of the Integrity of the product 
file, operator approval is requested prior to proceeding 
with any update run. The following message Is displayed 
on the console: 



PAUSE 



UPDATE RUN - GO OR DROP 



An operator response of GO causes the update run to pro- 
ceed; an operator response of DROP causes the job to be 
dropped. 

Update runs are made initially to create the product file 
and detail file; subsequently to add or delete a product, to 
make a product active or inactive, and/or to alter pro- 
tection parameters. 

Protection parameters Include blanking of the account/user 
number field on reports, operator warning when the detail 
file has exceeded a specified number of words, and thres- 
hold values per product with an overriding control 
parameter (see Parameter Card subsection in section 2). 



SUMMARY RUNS 

Summary runs extract and accumulate usage totals for all 
products on the product file and produce a summary report 
of product usage for the past six months up to the current 
time. Like a billing run, a summary run extracts usage 
detail records from the usage detail file and accumulates 
usage liability, but the summary report reflects all usage 
up to the current date and time. A summary run does not 
purge any records from the usage detail file like the bill- 
ing run does. Thus, a summary run will not cause con- 
solidation of the usage detail file to make more rotating 
mass storage space available. A summary run Is specified 
by the word SUMMARY on the parameter card (see the 
Parameter Card subsection in section 2. ) 

In addition to producing summary reports for each vendor 
code, a system status report is also produced Indicating 
run type and status, usage detail file status, and product 
file status. 



Upon termination of an update run an update report is 
generated indicating the changes made to the product file 
as well as any errors that may have occurred on the Input 
data deck. A system status report Is generated Indicating 
the type of run, its termination status, and the status of 
the product file and the detail file. (For a description of 
the various reports, see the Report subsection in section 2. ) 



DATA DECK 



The data deck is the user's means of communicating direc- 
tives to RANDR. Through the use of the data cards, the 
user can specify the type of run (update, summary, or 
billing), update the customer or CDC mailing address, or 
update the product file itself. Four card types are accepted 
by RANDR as input: 
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• Parameter, 

•r Control Data record, 

• Customer record, and 

• Product activity. 



,d 



Column 



1 to 4 



7to 9 
10 to 14 

15 
16 



17 
18 
19 

20 to 26 



Format 



Parameter 
code 

blank 
ptp 



blank 
detsz 

blank 
actp 



blaiik 

Id 

n 

type 



RANDE sorts the Input by card identifier prior to the 
start of the processing. Thus the data cards may be in 
any order. 

PARAMETER CARD 

The parameter card inputs to RANDR the type of run to be 
performed and the number of copies to be generated for 
the various reports. 

Example 



code ptp detsz actp id n type 



fcY73 



999 N 1 



UPDATE 



27 to 80 



blank 



Description 

A four- character alphanumeric code which identifies the hardware 
type (CPU model code). This code is used only during the creation 
of the product and detail files. (The appropriate code is to be 
chosen from the table In Appendix C. ) 

Reserved. 

Product threshold protection indicator, where: 

Y - specifies that special checking at the initiation and 

completion of all products is to be done. 

N - specifies no usage protection or special checking Is 
to be done. 

Blank - on creation defaults to N; on subsequent updates no 
change. 

Reserved. 

Value for detsz is multiplied by 1000 and specifies the size at which 
the operator will be notified. Zero implies no checking or warnir^ 
(see table 2-3). A blank on creation implies 0; on subsequent update 
runs it Implies no charge. 

Reserved. 

Account/user number protection, where: 

Y - specifies that the account/user number field will be 

blanked; 

N - specifies that the account/user number field will appear 
on detail reports; 

Blank - on creation defaults to N; on subsequent update runs 
indicates no change. 

Reserved. 

Value for id must be 1. This identifies the card as a parameter card. 

Value for n is 1 to 9. This entry indicates the number of copies of 
the reports the user desires to receive. Default value Is 1. 

This identifies the type of run to be performed; either UPDATE, 
BILLING, or SUMMARY, where: 

UPDATE - allows the above Installation information to be initiated 
and subsequently altered; 

BILLING - produces a summary report of the previous six-months 
liability (columns 1 to 17 are ignored). 

SUMMARY- produces a current product usage liability report 
(columns 1 to 17 are ignored). 

Reserved. 
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NOTE 

On bllUr^ runs , the number of report copies pro- 
duced is the number requested by the user on the 
parameter card, plus one additional copy for 
Control Data. For example, if the user specifies 
a value of 2 for the n parameter on the parameter 
card, then the run generates three copies of all 
the reports for each vendor code. The user, in 
turn, must then forward one copy of the summary 
. report to the Control Data office specified on the 
reports. 

Durti^ a RANDR run, the input data deck may consist only 
of a parameter card, specifying the run type in columns 20 
to 26. A single parameter card specifying UPDATE modi- 
fies the protection parameters, providing the product file 
is alrea(fy established. 

For the initial update run, the input consists of the para- 
meter card (ld=l), the appropriate number of Control 
Data and customer record cards (id=2,3), and at least 
one product card (id=4). Subsequent update runs may con- 
sist of any type (Id=l,2,3, or 4) of cards. 



Errors detected upon input of the parameter card are indi- 
cated on the update report (see the Update Report subsection 
in section 2). 



CONTROL DATA RECORD CARDS 

The Control Data record cards are a series of three cards 
which contain the name, address, and contact of the 
Control Data office to which billing reports are to be sent. 

The Control Data cards contain the address of the Control 
Data regional accounting office to which the summary re- 
port is to be sent by the user on a monthly basis. Only 
one set of Control Data cards may be input to the product 
name file and It need only be done once. Update errors 
are displayed on the update report (see the Update Report 
subsection in section 2). 

Errors on input are defined in tables 2-1 and 2-2. 



Format 





T" 


sn 1 ine 5 


J 


id sn 


line 3 line i( 






/ _, 


sn 


ine 1 line 2 






' id 







Example 

2 3 (6l2)853-%225 
2 2 8100 3^ AV S. MINNEAPOLIS, MN SS^O 
2 1 CONTROL DATA CORPORATION MIDWEST REGIONAL SALES OFFICE 



Column 
1 to 17 
18 
19 



Parameter 
blank 
id 

sn 



Description 



Reserved. 



20 to 79 



line n 



80 



blank 



Value for id must be 2, Identifies this card as a vendor record card. 

sn is the sequence number of the vendor record card. The values of 
1,2, and 3 are assigned to vendor information as follows: 

1 = lines 1 and 2; 

2 = lines 3 and 4; and 

3 = line 5. 

n is a number 1 to 5 representing one of the following five lines of 
vendor information: 

line 1 = corporation name (columns 20 to 49); 

line 2 = regional accounting office (columns 50 to 79); 

line 3 = street address; 

line 4 = city, state, and zip code; and 

line 5 = area code and phone number. 

Reserved. 
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CUSTOMER RECORD CARDS 

The customer record cards are a series of three cards 
containing the name, address, and contact of the user. 



This information is used by Control Data to identify the 
user submitting the billing reports. 



Format 



id sn 



I ine 5 



id 



sn i ine 3 



t ine h 



Id sn 1 ine 1 1 ine 2 



Example 



3 3 C/0 CIWIG HANSON EXT-3200 



3 2 BURLINGTON, MISSISSIPPI 30526 (304)222-6800 



3 1 ABACUS DATA CORPORATION 1512 QUINCY AVENUE 



Column 



Parameter 



Description 



1 to 17 
18 



blank 
id 



Reserved. 

Value for id must be 3, Identifies this card as a customer record 
card. 



19 



20 to 79 



line n 



sn is the sequence number of the customer record card. The 
values of 1, 2, and 3 are assigned to customer information as 
follows : 

1 = lines 1 and 2; 

2 = lines 3 and 4; and 

3 = line 5. 

n is a number from 1 to 5 representing one of the following five 
lines of customer information: 

line 1 = customer name (columns 20 to 49); 

line 2 = street address (columns 50 to 79); 

line 3 = city, state, and zip code (columns 20 to 49); 

line 4 = area code and phone number (columns 50 to 79); 
and 



80 



blanlc 



line 5 = contact's name and phone extension (columns 20 
to 49), 



Reserved. 
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Only one set of customer record cards may be input to the 
product name file. Subsecjuent runs (with id=3 cards) alter 
the existing records. Errors detected on input of the cus- 
tomer record cards are displayed on the update report (see 
the Update Report subsection in section 2). 

PRODUCT ACTIVITY CARDS 

Product activity cards are the user's means of indicating 
to RANDE that new products are to be installed on the 



system (add function); that old products are to be removed 
from the system (delete function); that a product is to be 
active or Inactive; and/or that the threshold values for 
usage protection are to be changed. 

The information on a product activity card consists of all 
the information necessary for RANDE to associate a soft- 
ware and vendor code combination, generated by the appli- 
cation, with the product itself. 



Format 



c 



vc product id tr swc 



Column 



1 to 2 



3 to 12 



Parameter 



product 



Example 



(l 



VC COBOL 



ABCD 



13 



blank 



Description 

A two-character vendor code designating the vendor of the product. 
The vendor codes CD, OO or W> (l5=space) are reserved for Control 
Data's use only. All products with any of these three vendor codes 
are subject to usage pricing liability. 

Up to 10 characters designating the product name. Duplication of 
the product name is permitted by RANDE, but no two products may 
have the same product name vendor code and software code as well. 
In the event of duplication, EANDE will merely add the new informa- 
tion to the existing product; thereby dissolving the uniqueness of the 
two products. 

Reserved. 



14 



tr 1 



15 
16 



blank 
tr 2 



A transaction code used to maintain product file, where: 

A = add product information to product file; 

D = delete product information from product file; and 

Blank = on creation run defaults to A; on subsequent runs this 
indicates no charge. 

Reserved, 

A transaction code used to alter product status where: 

A = active (product is active and can be used); 

I = inactive (product is inactive and no us^e will be 
allowed until status is reset); 

Blank = on creation, run defaults to A; on subsequent runs, this 
indicates no change. 



17 
18 



blank 
id 



Reserved. 

Value for id must be 4. 
activity card. 



This identifies the card as a product 



19 

20 to 23 



blank 
thldd 



Reserved. 

Value for thldd is multiplied by 1000 and is used as a threshold of 
usage. When the usage units for a product and a specific software 
code have accumulated beyond this threshold, the product and its 
software code are set inactive. No further use is allowed until a 
noninterim billing run is made, or RANDR is run with appropriate 
Input to reset the product. A warning of this action is put out to the 
user dayflle, the system dayfile, and the operator (see table 2-3). A 
is treated as no such protection. A blank implies a 0. 
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Column 



Parameter 



Descrtptton 



24 



blank 



Reserved. 



25 to 29 



thldw 



30 to 80 



Value for thldw is multiplied by 1000 and is used as a threshold of 
usage. When the usage units for a product and a specific software 
code have accumulated beyond this threshold, a warning is put out 
to the user dayfile, the system dayfile, and the operator (see table 
2-3). This value must be less than thldd or it is flagged in error. 
A is treated as no protection. A blank implies a 0. 

Software codes for the product. Up to four-character software codes 
designatir^ a particular job step of the product. Software codes are 
delimited by commas (, ). Software codes of less than four characters 
are left- justified, blank-filled, by RANDR. [ For example, valid 
software codes are: A, AB, ^AB2, A2B3. Invalid software codes 
are: ABCDEFG (no comma delimiter), WW (reserved for CDC 
only). ] 



Product records which have been set inactive as a result 
of the specified threshold value can be reset with a product 
activity card specifying I for transaction code 2, and either 
increasing the threshold value or setting it at 0. 

NOTE 

H threshold protection was set N via a parameter 
UPDATE card (id=l), then no usage accumulation 
checking nor product status checking is 
performed. 

Continuation cards on the product activity cards are not 
permitted, nor are they needed because two or more pro- 
duct activity cards with the same vendor code and product 
name are permissible, as long as no duplication of soft- 
ware codes exists. Duplication of vendor and software codes 
in the input deck causes the second occurrence to be flagged 
as an error on the update report. That is, two operations 
on the same record within the same update run are illegal. 
An update of a record that already exists on the file (that 
is, all status and protection fields are identical) will still 
cause a replacement of that record with an indication that 
the record exists already. 

Deletion of records does not take place at the time of the 
RANDR run, but rather, a status subject to deletion is 
placed on the record. The record will be deleted after the 
next billing run is made if all product activity has ceased 
(see the Usage Summary Report subsection In section 2). 



NOTE 



Users who for tracking purposes wish to Install 
their own applications under RANDR are cau- 
tioned to ensure that no two vendor code/software 
code combinations are identical. To prevent 
conflict of vendor products with Control Data 
leased products, all Control Data products will 
use one of the following vendor codes: CD, OO 
or W 0<=space). User employment of these 
codes will cause the usage of the application to 
be placed on the CDC portion of the reports. 



Product activity card information for all Control Data 
applications subject to usage pricing is supplied to the 
user by Control Data via the Applications Installation 
Handbook. 



REPORTS 

The reports produced by RANDR inform the customer of 
the status of maintenance runs as well as report usage of 
all applications under the Usage Accounting Utility. Four 
reports are produced by RANDR depending upon type of 
run: 

• Update report (update); 

• Usage detail report (summary, billing); 

• Usage summary report (summary, billing); and 

• System status report (update, summary, billing). 

A standard header appears on every page of each report. 
The heading format Is shown on each sample report In- 
cluded tn this section. 



UPDATE REPORT 

The update report Is an account of all the transactions of 
an update run. The report is broken up into four parts 
to coincide with the data card Input. Figure 2-2 shows a 
sample of the update report. The numbers within a circle 
correspond with the fields described as follows. 
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Item 



Field 



Description 



10 
11 

12 

13 

14 



15 

16 

17 

18 



TITLE 
PREPAEED 
PAGE 
PARAMETER CARD 

COPIES 



RUN TYPE 

CARD 

MESSAGES 

CDC RECORD 

CRD SEQ 
TRANSACTIONS 

ACTION 

CUSTOMER RECORD 
PRODUCT ACTIVITY 



VENDOR CODE 

PRODUCT NAME 
SOFTWARE CODE 



UNIDENTIFIABLE 
CARDS 



Tjrpe of report. 

Date of preparation. 

Page number. 

Indicates that the items following were the input on the 
parameter card. 

Indicates the number of copies of each report that will be 
produced upon run termination. 

NOTE 

One extra copy of each billing report that is to be 
sent to Control Data is automatically produced. 

Indicates the type of run request: update, billing, or 
summary. 

The physical position of the card which caused the trans- 
action within the data deck. 

Indicates that a questionable situation has been encountered 
by processing the input card. Table 2-1 contains a list of 
the error messages which can appear on an update report. 

Name/address fields of Control Data record input. Five 
lines of information are permissible. 

Sequence number of the vendor or customer record cards. 

Update run input directive: add (A) or delete (D), active 
(A) or inactive (I). 

Action taken by RANDR as a result of the function and 
directive input. Action taken may be ADDED, DELETED, 
or IGNORED. 

Name/address fields of customer record Input. 

Indicates that the following section contains all the Input 
transactions against a specific vendor code. The number 
of sections to the product activity report is dependent upon 
the number of different vendor codes input during the 
update run. 

Two-character mnemonic indicating the product's vendor. 
Codes CD, 00 and M, are reserved for Control Data 
products. 

Ten-character name associated with the product. 

One- to four- character mnemonic assigned to a software 
product job step. One product may have any number of 
software codes assigned to it. The number is determined 
by the structure of the application program itself. 

When a card is input that cannot be fully processed during 
the update run, the card image of the erroneous card is 
displayed in this section. 
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USAGE DETAIL REPORT 

The usage detail report contains a sequential list of all 
application product job steps subject to usage pricing since 
the last billing run was made. Entries in the detail report 
are arranged in a chronological order by software code 
within product name. Each vendor code produces a sep- 
arate detail report. Usage liability is itemized by job 
step, total per software code, total per product, and total 
per vendor. Figure 2-3 shows a sample usage detail re- 
port. This report Is put out for both summary and billing 



Item 
1 
2 
3 
4 



9 
10 
11 
12 
13 
14 

15 
16 
17 
18 
19 



Field 
TITLE 
PREPARED 
PAGE 
VENDOR: CDC ADDRESS 

SPECIAL INSTRUCTIONS 

CUSTOMER 
PRODUCT NAME 

SOFTWARE CODE 

JOB BANNER 
ACCOUNT/USER NUMBER 
RtnSf DATE 
START/END TIME 
AUU STEP QUANTITY 
AUU TOTALS 

Unlabeled 
Unlabeled 
Software code total 
PRODUCT TOTAL 
VENDOR TOTAL 



runs, with special Instructions for billing runs. The 
period covered by the summary run Is from the end of the 
previous billii^ period through the current date and time. 
The period covered by the billing run is from the end of 
the previous billing period through the end (or current 
date in case of interim billing) of the billing month. 

NOTE 



Usage detail reports from billing runs for vendor 
code CD must be retained. 

Description 

T3rpe of report. 

Date of preparation. 

Page number. 

Vendor code of report section; Control Data name and 
address. 

When present, this indicates that one copy is retained or 
sent to the Control Data address specified under the 
vendor code. 

Name and address of the customer. 

Alphabetical list of products (one to 10 charachters) per 
vendor. 

Alphabetical list of a software codes per product (one to 
four characters). 

Job name of job generating usage. 

Account or user number generating usage. 

Date of run. 

Time of start and end of job step. 

Accumulated number of application us^e units (AUU). 

Total accumulated number of application usage units per 
software code, product, and vendor code, AUU totals are 
rounded to the nearest integer value; thus the total AUU 
for a particular software code may be 0. 

Run error Indicators (first three characters of the field). 

Nine- character record checksum. 

Software code AUU total per product. 

Product AUU total per vendor code. 

The total number of AUU used for all products within the 
vendor code. 
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USAGE SUMMARY REPORT 

The usage summary report contains the accumulative total 
of AUUs for each product and software code within the 
vendor code from the usage detail report. This report is 
produced for summary and billii^ runs. The difference 
between the reports for each type of run is that for billing 
rims, only records from the detail file with dates prior to 
the end of the billing month are reflected in the report. 



whereas for summary runs, all records from the detail 
file are reflected in the report. In addition, the report 
shows the number of AUUs used for all software codes 
over the previous five months and the total year-to-date 
number of AUUs since the software code was installed on 
the system. 

Figure 2-4 contains a sample usage summary reports Key 
items are listed below. 



Item 



Field 



Description 



1 to 6 



Standard Heading 



Reports to be sent to Control Data will have item 5 filled 
In with special instructions, while reports that are for the 
customer use only will have this field blank. 



PRODUCT NAME 



Alphabetical list of products per vendor (one to 10 
characters). 



SOFTWARE CODE 



Alphabetical list of software codes per product (one to 
four characters). 



EFFECTIVE DATE 



Date that the software code was entered into the product 
name file. 



10 



STATUS 



Software code special disposition status, where: 

S - indicates that the user wished the software code to 
be deleted but it was not due to usage activity dur- 
ing the current billing month. The software code 
will be dropped to D status during the next blllii^ 
month for which the software code shows no usage 
activity. 

D - Indicates that the user wishes the software code to 
be deleted. If the software code shows no activity 
during the month, the code will be deleted from the 
product name file and will not appear on future 
reports. 



11 



Y-T-D AUU USAGE 



Accumulated AUU Usage - Indicates the total number of 
AUUs consumed since the software code was entered into 
the product name file or for the current year. 



12 



PREVIOUS BILLING 
PERIODS 



Total number of AUUs consumed by the software code for 
the months indicated. The five previous billing periods 
are displayed. 



13 



CURRENT 



Total number of AUUs consumed during the current month 
for summary runs or the total for the last full month for 
billing runs. 



14 



TOTAL USAGE 



Y-T-D and monthly AUU totals of all software codes within 
a product. 



15 



Total usage entries followed by an asterisk (*) Indicate 
that a billing run was not made during these months and 
that the customer will be billed this month for the usage. 



16 



INV. AMT. 



Invoice amoimt - Indicates usage liability for current 
billing period. 



17 



ACCUM PRODUCT 
USAGE 



Total Y-T-D and monthly usage for vendor code. 
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SYSTEM STATUS REPORT 

The system status report contains information relating to 
the type of run and the status of the usage accwunting 



Item 



1 to6 



10 



Field 



Standard Heading 



AUU SYSTEM MONTH 



LAST BILLING MONTH 

AUU PRODUCT FILE 
STATUS 



AUU DETAIL FILE 
STATUS 



11 



TYPE OF EUN 



files. This report is produced regardless of the run type. 
Figure 2-5 contains a sample system status report. Con- 
tents of the data fields are: 



Description 

This report never contains special instructions in item 5. 
Therefore, the report need not be sent to Control Data. 

Month for which the run applies. For billing runs the 
AUU SYSTEM MONTH will be the last full month or part 
thereof. For summary runs, It includes the current 
system month as well. 

The system month of the last billing run. 

The status of the product name file where: 
NEW = file allocated during run. 
INACTIVE = file allocated previously but empty. 
ACTIVE = file allocated and not empty. 

The status of the detail file where: 

NEW = file allocated during run. 
INACTIVE = file allocated previously but empty. 
ACTIVE = file allocated and not empty. 

Indicates the type of run requested: BILLING, UPDATE • 
or SUMMARY. 



12 



13 



RUN TERMINATION 



Unlabeled 



The status of the run is shown as NORMAL or ABNORMAL. 
Runs with NORMAL termination may have had errors upon 
input, but the errors were not fatal. Abnormal run termi- 
nation occurs for fatal errors. 

For no errors, no message appears. For a trivial or 
fatal error this item contains a diagnostic message and 
an error code explaining the error. (A summary of these 
error codes and diagnostic messages is contained in 
table 2-2 of the error message section. ) 
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ERROR MESSAGES 

Error codes and error messages appear on the update 
report and the system status report whenever a question- 
able situation Is encountered during the processing of an 
input deck transaction. Diagnostic messages maybe trivial 
or fatal. For all trivial errors, RANDE continues pro- 
cessing the remaining transactions; fatal errors cause an 
abnormal run termination indicator on the update status 
report. 



Table 2-1 lists the errors that appear on the update re- 
port as a result of bad input data. Error types may be 
trivial (T) or fatal (F) as indicated in table 2-1. Trivial 
errors produce NORMAL run termination. Fatal errors 
produce ABNORMAL run termination and a fatal error 
code and message as listed in table 2-2. Fatal errors 
appear on the system status report. 



TABLE 2-1, UPDATE REPORT ERRORS 



Error Code/Message 



01-SWC NOT FOLLOWED BY COMMA 

02-SEQUENCE NUMBER ERROR 

03-PRODUCT CODE INVALID 

04-SOFTWARE CODE INVALID 

05-TRANSACTION CODE INVALID 
06-RECORD IS NOT ON FILE 

07-RECORD ALREADY ON FILE 

08-PROTECTION PARAMETER ERR 
09-INVALID RUN PARAMETER 

10-DETAIL SIZE PARAMETER ERR 



11-COPY PARAMETER ERR-1 
ASSUMED 



12-DUPLICATE VENDOR/SWC CODES 



13-DUPLICATE SEQUENCE NUMBER 



Error 
Type 



T 
T 



T 
F 



14-IDENT CODE INVALID 



Cause 



More than four characters en- 
<juntered on product activity 
card without a comma. 

Sequence number on customer 
vendor record cards greater 
than 3, 

Product name on product activity 
card invalid. Product name of 
all blanks is Invalid. 

Software code or product activity 
card invalid. All blanks or all 
zeros is invalid. 

Code not a A or D. 

Attempted to delete software 
code for a product which is 
nonexistent. 

Attempted to add a software 
code/product/vendor code which 
exists from previous run. 

Parameter is Ignored. 

Run type not BILLING, 
SUMMARY, or UPDATE on 
parameter card. 

Detail size specified; probably 
nonnumeric. 

Nonnumerlc copies specified on 
parameter card. 



Vendor/ software code combina- 
tion already exists on file. 

Move than one card of a vendor 
or customer record has the 
same sequence number. 

id code on input card greater 

than 4. 



Corrective Action 



Correct software code in 
error and rerun update. 



Correct card and rerun. 



Correct card and rerun. 



Correct card and rerun. 



Correct code and rerun. 

Possible keypunch error. 
Correct if necessary. 



None. 



Correct deck and rerun. 

Correct parameter and 
rerun. 



Correct deck and rerun. 



Run will continue and use a 
default of 1 as number of 
report copies to produce. 

Run continues. 



Correct vendor or custo- 
mer record cards and 
rerun, 

correct invalid card and 
rerun. 
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TABLE 2-1. UPDATE REPORT ERRORS (Cont'd) 





Error 






Error Code/Message 


Type 


Cause 


Corrective Action 


15-THRESHOLD VALUE NOT NUMERIC 


T 


Nonnumeric value other than 


Correct invalid card and 






blanks found in threshold values. 


rerun. 


16-REPLACES PREVIOUS CARD 


T 


Duplicate parameter cards 
found. Last one overrides. 


None. 


17- THRESHOLD VALUES INCONSISTENT 


T 


Value specified for product 


Correct invalid card and 






deactivation threshold not larger 


rerun. 






than that threshold specified for 








warning. 





TABLE 2-2. SYSTEM STATUS REPORT ERRORS 



Error Code/Message 


Cause 


Corrective Action 


Ol-Reserved 






02-NO DATA CARDS 


No input found for RANDR run. 


Correct deck and rerun. 


03-REJECT RELEASING 
FILE 


Operating system interface failure. 


See Product and Usage Detail Files descrip- 
tion in Application Installation Handbook, 


04-REJECT CREATING 
FILE 


Operating system Interface failure. 


See Product and Usage Detail Files descrip- 
tion in Application Installation Handbook. 


05-PARAMETER CARD 


Parameter card missing from update 
input deck. 


Correct deck and rerun. 


06-MISSING CDC RECORD 


One or more Control Data record cards 
missing during update run. 


Insert missing Control Data cards and 
rerun. 


07-NO CDC RECORDS 


No Control Data address record cards 
found. 


Insert cards and rerun. 


08-CARD SEQUENCE 
NUMBER ERR, 


Sequence numbers on data cards impro- 
perly sequenced. 


Correct cards and rerun. 


09-MISSING CUSTOMER 
RECORD 


Customer record not input or there are 
not three customer record cards input 
during update run. 


Input complete set of customer record 
cards. 


lO-INVALTD INPUT CARD 
DECK 


Input card in data deck not in correct 
format. 


Correct card(s) and rerun. 


11-DUPLICATE 

PARAMETER CARD 


More than one parameter card in input 
deck. 


Remove duplicate card and rerun. 


12-INVAT,m RUN 
PARAMETER 


Run type parameter is other than UP- 
DATE, BILLING or SUMMARY, 


Correct parameter card and rerun. 


13-INVAT,Tn INPUT DECK 


Input deck for RANDR found to be 
invalid. 


Correct deck and rerun. 


14- CUSTOMER RECORD 
ERROR 


Customer record card not formatted 
correctly on update run. 


Correct error and rerun. 


15- VENDOR RECORD 
ERROR 


Vendor record card not formatted 
correctly on update run. 


Correct error and rerun. 
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TABLE 2-2. SYSTEM STATUS REPORT ERRORS (Cont'd) 



Error Code/Message 



16-NO PRODUCT FILE 



17-PRODUCT FILE EMPTY 



18-NO DETAIL FILE 



19-DETAIL FILE EMPTY 



20-REJECT RETURNING 
FILE 

21-INVALID SYSTEM DATE 



22-AUU/SYSTEM DATES 
CONFLICT 



23-EXCESS BILLING 
PERIODS 



24-REJECT CATALOGING 
FILE 

25-REJECT ON FILE 
RENAME 

26-TEMP PRODUCT FILE 
EXISTS 

27-TEMP DETAIL FILE 
EXISTS 

28-REJECT PURGING FILE 



29-FATAL ERRORS IN 
UPDATE 

SO-INVAUD MACHINE TYPE 



Cause 



Product file not In system. 



No data in product file on billing or 
summary run. 

Detail file not in system. 



No data in detail file durii^ a billii^ or 
summary run. 



Operating system interface failure. 



Operating system date not in valid 
range. 

Date of last billing run is not at least 
one month prior to current system 
month. 

A billing rvin has not been run in last six 
months, therefore, itemized monthly 
INV. AMT. are not available for month 
previous to the sixth previous months. 

Operating system interface failure. 



Operating system interface failure. 



Operating system interface failure. 



Operating system interface failure. 



Operating system interface failure. 



Fatal errors found during update run. 



Operating system interface failure. 



Corrective Action 



Load product file from last dump tape. If 
no dump tape exists, run update with pro- 
duct activity card and type GO when pro- 
duct file message appears. 

Run update with product activity cards. 



Load detail file from last dump tape. If 
no dump tape exists, run update and type 
GO when detail file messsige appears. 

Summary or billing run, but no detail 
records have accumulated yet. This 
particular situation is not always an 
ABNORMAL fatal error. If the detail 
file is in good order (NORMAL termin- 
ation) but contains no detail usage ent- 
ries, all reports except the detail usage 
reports are generated. ABNORMAL 
termination indicates that the detail 
file is invalid and probably needs to 
be recreated. 

See Product and Usage Detail Files descrip- 
tion In Application Installation Handbook. 

Deadstart system and enter correct date. 



Walt until month change occurs to run 
billing run. 



Billing runs must be run at least every 
six months to maintain monthly liability. 



See Product and Usage Detail Files descrip- 
tion in Application lastallation Handbook. 

See Product and Usage Detail Files descrip- 
tion in Application Installation Handbook. 

See Product and Usage Detail Files descrip- 
tion in Application Installation Handbook. 

See Product and Usage Detail Files descrip- 
tion in Application Installation Handbook. 

See Product and Usage Detail Files descrip- 
tion in Application Installation Handbook. 

Check update report. Correct problem 
and rerun. 

See Product and Usage Detail Files descrip- 
tion in Application Installation Handbook. 
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TABLE 2-3. OPERATOR WARNING MESSAGES 



Error Code/Message 


Cause 


Corrective Action 


PAUSE NO PRODUCT FILE 


The product file was not found for a 


Type n. DROP, reload last product file 


LOAD PRODUCT FILE - 


RANDR run. - 


and rerun or type n. GO and continue. 


GO OR DROP 






PAUSE NO DETAIL FILE 


The detail file was not found for a 


Type n. DROP, reload last product file 


LOAD DETAIL FILE - GO 


RANDR run. 


and rerun or type n. GO and continue. 


OR DROP 






PAUSE UPDATE RUN - GO 


An update run has been specified by the 


Verify a product file update was re- 


OR DROP 


input to RANDR. 


quested and type n. GO. 


VC swc PRODUCT 


The deactivate threshold has been ex- 


Run full month billing run or RANDR 


DEACTIVATED 


ceeded and the product deactivated. 


to reset status and threshold. 


VC swc PRODUCT 


The warning threshold has been exceeded 


No action necessary. 


THRESHOLD REACHED 


but the product status remains active. 




USAGE DETAIL FILE SIZE 


The specified number of words has been 


Type n. GO; make bllUng run if disk 


EXCEEDED - TYPE N. GO 


reached on the detail file size. 


space is required. 
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ACOUNTX OPERATION 



ACOXJNTX 1b the sole interface which a usage priced 
application, whether that of Control Data or of the user, 
has with the accounting flies and the accounting system. 
ACOUNTX Is available for programs written In FORTRAN 
Extended 4 (FTN 4), COBOL 4 and COMPASS 3. 

Generally, an application will make two calls to ACOUNTX, 
one to start application usage accounting, and the second 
to end accounting for each job step within the run. How- 
ever, intermediate calls to change application usage unit 
(AUU) rates or limits may also be made between the start/ 
end envelope as need requires. Change rate and change 
limit functions are also convenient methods for the appli- 
cation itself to obtain the current AUU liability and the 
number of system seconds (SS) consumed thus far. 

A system second, as used in this text, is a unit of measure 
of central processor activity. It represents the central 
processor resources used for the run multiplied by a 
constant. This constant is derived such that the number 
of system seconds remains the same for a given appli- 
cation rim regardless of the particular mainframe the 
application was executed on. 

Applications which end prematurely due to a system abnor- 
mal condition will have accounting terminated without the 
application making the end call. End processing under 
these circumstances causes end termination with error 
messages appearing on the system and user dayfiles and 
an error code placed in the job step associated accounting 
detail record in the usage accounting detail file. In addi- 
tion, upon occurrence of an abnormal abort situation, the 
register file and a dump of 100 octal words before and 
after the location where the error was detected are dumped 
to the output file to aid in locating the software/hardware 
problem (see Abnormal Errors subsection in section 3). 



APPLICATION USAGE ACCOUNTING 
CALLS 



COMPASS: 

SA1 PADDR 

RJ ACOUNTX 

VFD 12/Line Number, 18/Trace Word Address 



PADDR VFD 60/1 CODE ADDRESS OF 

PARAMETER 

VFD 60/ISFNAME ADDRESS OF 
PARAMETER 

VFD 60/ISC0DE ADDRESS OF 
PARAMETER 

VFD 60/ 1 RATE ADDRESS OF 
PARAMETER 

VFD 60/ISCHARG ADDRESS OF 
PARAMETER 

VFD 60/1 S ITEM ADDRESS OF 
PARAMETER 

VFD 60/IALIM ADDRESS OF 
PARAMETER 

VFD 60/IVENCD ADDRESS OF 
PARAMETER 

BSSZ 1 



PARAMETER DEFINITION 



FUNCTION 
PRODUCT NAME 
SOFTWARE CODE 
SOFTWARE RATE 
SURCHARGE RATE 
ITEM CODE 
AUU LIMIT 
VENDOR CODE 



The parameter list specification of calls to ACOUNTX is 
variable in length with fixed-position parameters. Null 
fields should not be used in the parameter for FTN 4 and 
COBOL 4 (that is, (, , ) should not be used). Instead (, 0, ) 
or (, ]i, ) should be used to indicate the presence of a null 
parameter in the string (where ]6 indicates a space). This 
technique may be used for any optional parameter which 
the application does not need or for a parameter that 
ACOUNTX does not use for a specific function call. 



Application calls to ACOUNTX follow the standard oall-by- 
name convention specified for COBOL 4, FTN 4 and 
COMPASS 3. Up to eight parameters are accepted by 
ACOUNTX; one specifying the function to perform and up 
to seven other parameters, depending upon the function. 
The general forms of all calls to ACOUNTX are as follows: 

• FORTRAN Extended (FTN 4): 

CALL ACOUNTX (ICODE, ISFNAME, ISCODE, IRATE, ISCHARG, 
ISITEM, lALIM, IVENCD). 

• COBOL 4: 

ENTER FORTRAN-X ACOUNTX USING ICODE, ISFNAME, ISCODE, 
IRATE, ISCHARG, ISITEM, lALIM, IVENCD. 



ICODE (left justified, blank, or zero fill). A 
literal that defines the function to perform (5 or 
6 characters). 

1. Start AUU accounting. 
5LSTAUU, 5HSTAUU 

2. Change AUU rate. (Used also by the appli- 
cation to obtain the number of AUUs con- 
sumed by the application. ) 

5LCRAUU, 5HCRAUU 
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3. Change AUU limit. (Used by the application 
to obtain the number of system seconds con- 
sumed by the application. ) 

6LLIMAUU, 6HLIMAUU 

4. End AUU accounting. 
5LEDAUU, 5HEDAU.U 

ISFNAME (left justified, blank, or zero fill). A 
literal (one to 10 characters) used to designate 
the name of the software product. This literal 
can, but need not, correspond to the product 
name on the product name file. The literal is 
displayed in the system dayfile and user dajrfile 
in the start messages associated with the appli- 
cation run. 

BCODE (left justified, blank, or zero fill). A 
literal used' as the software code to designate a 
■particular job step within a vendor product (one 
to four characters). ISCODE may be duplicated 
within the system, however, the combination of 
software code (ISCODE) and vendor code 
(IVENCD) must be unique. RANDR checks to 
guarantee that no two vendor code/software code 
combinations are duplicated, 

IRATE (integer or variable containing an integer). 
A positive integer constant that gives the AUU/SS 
rate. The value is in hundredths of an application 
usage unit (AUU). Thus if the user wanted to 
charge 2. 5 AUUs per SS, IRATE would contain 
250. 

ISCHARG (integer or variable containing an inte- 
ger). A positive integer that is added to the 
application usage unit (AUU) accumulator. The 
value is a whole number value which is added as 
a surcharge to the accumulated AUUs. Thus if 
the user wished to add 50 AUUs to the AUU accu- 
mulator at the termination of a job step, 
ISCHARG should contain 50. 

If the ISCHARG parameter is specified during a 
change rate or an end accounting call, ACOUNTX 
places the AUUs accumulated thus far during the 
job step in ISCHARG in the form: 



ISCHARG 



52_ 



47 



2 



ACC 



ACC = accumulated AUUs (ACC is in thousandths of AUUs). 

It is for this reason that the input parameter 
ISCHARG must be a variable rather than a con- 
stant or a literal. The returned variable is in 
thousandths of an AUU. Thus a value of 120505 
would indicate that 120. 505 AUUs were consumed 
this far during the job step. 

• ISITEM (left justified, blank, or zero fill). A 
four-character literal used as the item code. 



This parameter has no meaning. Any literal in 
this field is displayed in the start message for 
the application job step in the user dayfile and the 
system dayfile. 

lALIM (integer or a variable containing an inte- 
ger). A variable field specified by the calling 
application used by ACOUNTX to return the num- 
ber of system seconds (SS) accumulated by the 
application job. The returned value is a positive 
integer in thousandths of a system second. Thus 
a value of 102031 returned to the application as a 
result of a start or change limit call to ACOUNTX 
would indicate that 102 seconds and 31 milli- 
seconds were consumed this far. Because lALIM 
is used by ACOUNTX to return parameters, 
lALIM must be specified as a variable rather than 
a constant or a literal value. The returned para- 
meter lALIM takes the form: 



59 



47 



11 







lALIM 



2 


SEC 


MS 



SEC = system seconds accumulated. 
MS = system milliseconds accumulated. 

IVENCD (left justified, blank or zero fill). A 
two-character literal that is used as the vendor 
code. This parameter is absolutely required on 
all start calls to ACOUNTX from non-CDC appli- 
cations. CDC applications automatically have a 
vendor code of CD, 00 or ]S]i ()!$=space) assigned 
by ACOUNTX as would user applications that do 
not specify an IVENCD parameter on the start 
call. It Is for this reason that user applications 
calling ACOUNTX choose an IVENCD of two char- 
acters other than CD, 00 or W. If the user 
application supplies one of these three codes as 
their vendor code, the system will assume Control 
Data usage pricing liability for the application run. 



PARAMETER USAGE 



An application job step is defined as the interval between 
a start and end accounting call. Multiple calls to 
ACOUNTX to change rate or change limit are permissible 
after a start and prior to an end call or another start call. 
Two start calls without an end will cause automatic termi- 
nation of the first start sequence without any error 
Indication. 

Each call to ACOUNTX requires the function to be defined 
(that is, STAUU, CRAUU, LIMAUU or EDAUU) and from 
zero to seven parameter specifications depending upon 
the ACOUNTX call. Table 3-1 defines the required, 
optional, and parameters not used for each function call. 
Furthermore, the parameter string may be terminated 
immediately after the last required parameter of the call. 
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TABLE 3-1. PARAMETER USAGE TABLE 



ICODE 


ISFNAME 


ISCODE 


IRATE 


KCHARG 


ISITEM 


lALIM 


IVENCD* 


STAUU 


OP 


RQ 


. RQ 


NU 


OP 


OP 


RQ* 


CEAUU 


NU 


NU 


RQ 


RQ 


NU 


NU 


NU 


LIMAUU 


NU 


NU 


NU 


NU 


NU 


RQ 


NU 


EDAUU 


NU 


NU 


NU 


OP 


NU 


NU 


NU 




Code 


Meaning 






RQ 


Required parameter. Diagnostic is issued if parameter is missing 
and in some cases if the parameter value is zero or blank. 






OP 


Optional parameter. 






NU 


Not used. ACOUNTX does not use these values contained In the 
parameter nor does it return any values in them. 






+ 


rVENCD is a required parameter only for user supplied applications 
and an optional parameter for CDC applications. If this parameter 
is used In CDC supplied applications, the code must be "CD". 



PARAMETER FORMATS 



The parameter list specification for calls to ACOUNTX 
are variable length fixed position parameters. Parameters 



not needed for the particular call may be omitted but the 
delimiter (, 0, ) or (, \i, ) must be used to indicate the omis- 
sion. All parameters must start on a word boundary and 
agree in type with that shown in table 3-2. 



TABLE 3-2. PARAMETER FORMATS 



Parameter 


Type 


FTN 


COBOL 


ICODE 


Literal 


5LSTAUU 


PIC X(10) VALUE ^STAUU^ 


ICODE 


Literal 


5LCRAUU 


PIC X(10) VALUE j^CRAUU?^ 


ICODE 


Literal 


6LLIMAUU 


PIC X(10) VALUE ?^LIMAUUi^ 


ICODE 


Literal 


5LEDAUU 


PIC X(10) VALUE ^EDAUUt^ 


ISFNAME 


Literal 


lOHXXXXXXXXXX 


PIC X(10) VALUE ^XXXXXXXXXX?^ 


ISCODE 


Literal 


4LXXXX 


PIC X(10) VALUE ;^XXXX^ 


IRATE 


Integer 


Integer Variable 


PIC 9(10) 


ISCHARG 


Integer 


Integer Variable 


PIC 9(10) 


ISITEM 


Literal 


4LXXXX 


PIC X(10) VALUE /XXXXj^ 


lALIM 


Integer 


Integer Variable 


PIC 9(10) 


IVENCD 


Literal 


2LXX 


PIC X(10) VALUE ?^XX^ 



NOTE 

The level number of all COBOL parameters must 
be level 1 to guarantee that parameters start on 
a word boimdary. 
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ACOUNTX MESSAGES 



CALLING ERRORS 



Durir® normal processing of accounting calls, ACOUNTX 
displays start and end messages on the user and system 
dayflle containing tracking information relative to' the job 
step, (Appendix B contains sample user dayfiles display- 
ing ACOUNTX dayfile messages. ) 



START MESSAGE 

The start message appears on the user and system day- 
files every time a valid start function (STAUU) is received 
by ACOUNTX, The message takes the following form: 

hh.mm.ss. SWCS vc swc softwrname icde 

where: 

hh.mm.ss = time of entry (hours /minutes /seconds). 

SWCS = indicates a start message. 

vc = vendor code (IVENCD parameter) for 
the application (two characters). 

. . swc = software code (ISCODE parameter) in- 
put to ACOUNTX (up to four characters), 

softwrname = software product name (ISFNAME para- 
meter) if specified in the call (10 char- 
acters). 

Icde = Item code (ISITEM parameter) if speci- 
fied in the call (four characters). 

END MESSAGE , 

The end message appears on the user and system dayfiles 
upon termination of an application job step either through 
an EDAUU call, another start call (STAUU) without a sub- 
sequent end call, or an abnormal termination by the sys- 
tem. The end message takes the followii^ form: 

hh.mm.ss. SWCE vc swc AUUS USED = xxxxxx.xxx 
hh.mm.ss. AUUS ACCUMULATED = tttttt.ttt 

where: 

hh. mm. ss = time of entry (hours/minutes/seconds). 

SWCE = indicates an end message. 

vc = vendor code (IVENCD parameter) of the 
application (two characters). 

swc = software code (ISCODE parameter) in- 
put on the start call to ACOUNTX 
^p to four characters). 

xxxxxx.xxx = the number of AUUs consumed for the 
job step. 

tttttt.ttt = the total number of AUUs consumed 
thus far for the run. 



ACOUNTX aborts the application if an illegal function re- 
quest or an illegal parameter is received. An illegal 
function request results when a function other than STAUU, 
CRAUU, LMAUU, or EDAUU is specified as the first para- 
meter in the ACOUNTX calling sequence. Calling errors 
can also be caused when a required parameter is mlssii^ 
from the parameter list passed to ACOUNTX. A missing 
paranieter can occur when the parameter list is terminated 
by a zero word prior to the last required parameter for 
the particular call, In addition, a zero or null parameter 
is considered Illegal for some parameters (that is, ISCODE 
on start messages and IRATE on start and change rate 
messages). 

When an illegal function or invalid parameter is encountered 
by ACOUNTX the message; 

hh.mm.ss. AUU FUNCTION nn, ERR xx 

hh.mm.ss. ACOUNT- ILLEGAL PARAMETER (C=aa,P=y) 

is displayed on the user and system dayfiles and error 
codes are placed in the detail record for the job step (see 
the Usage Detail Report subsection in section 2). 

where: 

nn = a two-character code of from 01 to 06, where: 

01 = error on start AUU processing call, 

02 = error on change AUU rate call, 

03 = error on change AUU limit call, 

04 = error on end AUU accountir^ call, 

05 = unknown function input to ACOUNTX, and 

06 = force end of software accounting. 

and where: 

XX = a two-character numeric code of from 01 to 06 
indicating error type, where: 

01 = illegal software accounting request, 

02 = unknown software accounting function, 

03 = not used, 

04 = not used, 

05 = not used, and 

06 = illegal parameter. 
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and where: 



ABNORMAL ERRORS 



aa = a two- character alpha code indicating tjrpe of 
call, where: 

ST = STAUU call, 

CE = CEAUU caU, 

CL = LIMAUU call, 

ED = EDAUU call, and 

UN = unknown function call. 

and where: 

y = a one-character numeric code indicating para- 
meter error, where: 

1 = ICODE parameter in error, 

2 = ISFNAME parameter in error, 

3 = ISCODE parameter in error, 

4 = IRATE parameter in error, 

5 = ISCHAEG parameter in error, 

6 = ISITEM parameter in error, 

7 = lALIM parameter in error, and 

8 = IVENCD parameter in error. 

Calling errors cause AUU accounting to be ended normally 
with a normal end message (SWCE message) prior to job 
termination. 



Abnormal errors are any errors other than calling errors 
which normally would cause a system abort condition. 
Under these conditions, the application is not given the 
opportunity to call end accounting to terminate accounting. 
However, ACOUNTX sets up entries in the system which 
will force control to ACOUNTX's recovery code so that 
accounting can be closed out. Table 3-3 defines the error 
conditions which will initiate ACOUNTX recovery 
processing. 

When an abnormal error condition Is detected by the system, 
control is passed to ACOUNTX which terminates accounting, 
issues the accounting end (swce) message and banner mes- 
sage if accounting is active, and displays the AUU recovery 
message to the user and system dayfiles in the following 
format: 

hh.mm.ss. AUU RECOVERY ERROR CODE = xx 



where: 



XX = octal error code specified in the recovery error 
conditions table (table 3-3). 

NOTE 

For NOS, the exchange package will have 
registers Xl/Al, X6/A6 destroyed. 



TABLE 3-3. EECOVEEY EEEOE CONDITIONS 



Error Condition 


Error Codes 


(Octal) 


NOS/BE 


NOS 


Normal termination 


00 


— 


Time limit exceeded 


01 


01 


Arithmetic mode error 


02 


02 


PPU requested job abort 


03 


03 


CP program requested abort 


04 


04 


PP cannot be called from EA + 1 


05 


05 


Operator DROP 


06 


06 


Operator KILL 


07 


— 


Operator REEUN 


10 


~ 


CP abort 


11 


04 


ECS parity error 


12 


— 


System abort 


~ 


12 


Required auto-recall status missing 


15 


05 


Job hung in auto-recall 


16 


~ 


Required mass storage limit exceeded 


17 


— 


Track limit 


~ 


11 


XXX not in PP library 


20 


05 


lO time limit exceeded 


21 


~ 
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GLOSSARY 



ACOUNTX - Application interface which records the 
number of application usage units (AUU) consumed by an 
application. 

application charge (ISCHARGE) - A positive Integer speci- 
fying number of AUU's to add to the application usage unit 
accumulator as a surcharge. 

application limit (lALIM) - A variable field specified by 
the calling application used by ACOUNTX to return the 
number of system seconds (SS) accumulated by the appli- 
cation job. The returned value is a positive Integer in 
thousandths of system seconds. 

application rate (IRATE) - A positive integer constant 
specifying the number of AUU's/system second for an 
application job step, in hundreds of AUUs. 

application usage unit (AUU) - The base unit used to indi- 
cate the amount of usage of an application. 

bUltng run - RANDR run used to generate utilization reports 
of usage priced applications. Billing runs generate usage 
totals for up to six months prior to the current month. 

Control Data record cards (id=2) - A series of three cards 
specifying five lines of information, CDC name, address, 
telephone nuniber and contact (supplied by Control Data 
from software contract). 

customer record cards (id=3) - A series of three cards 
specifying five lines of customer information to be output 
on all reports. Information consists of customer name, 
address, telephone number and contact. 

detail usage file - Usage accounting file containing Infor- 
mation regarding each run made since the last billing run. 

function parameter (ICODE) - A five- or six-character 
literal defining the function to perform ICODE, Valid 
parameters are; 

STAUU - start accounting, 

CRAUU - change AUU rate, 

LIMAUU - return the number of system seconds con- 
sumed by the application, and 

ED AUU - end accounting. 

lALIM - Seventh parameter in the parameter string in a 
call to ACOUNTX (see application limit), 

ICODE - First parameter in the parameter string In a 
call to ACOUNTX (see function parameter). 

IRATE - Fourth parameter in the parameter string in a 
call to ACOUNTX (see application rate). 



ISCHARGE - Fifth parameter In the parameter string in a 
call to ACOUNTX (see application charge). 

ISCODE - Third parameter in the parameter string In a 
call to ACOUNTX (see software code). 

ISFNAME - Second parameter In the parameter string in 
a call to ACOUNTX (see product name). 

ISITEM - Sixth parameter in the parameter string in a 
call to ACOUNTX (see item code descriptor). 

item code descriptor (ISITEM) - A four- character literal 
used to further define the application job step. 

rVENCD - Eighth parameter in the parameter string In a 
call to ACOUNTX (see vendor code). 

parameter card (ld=l) - A card of the data deck used to 
specify the Usage Accounting Utility Installation parameters, 
required on creation run. Data on the card consists of 
hardware type, number of copies of each report to pro- 
duce, protection parameters and the type of run Update/ 
billing/summary) . 

product activity cards (id=4) - This set of data cards defines 
the valid products and software codes for each product to 
be usage priced. Information on these cards consists of 
vendor code for product, product name, valid software 
codes, the transaction codes (A - for add, D - for delete; 
A - for active, I - for inactive and threshold protection 
values). Product activity card Information for Control 
Data products is supplied to the customer in the Application 
Installation Handbook. 

product file - Usage accounting file used as a repository 
for product name, valid software names , customer /vendor 
Information, monthly AUU totals, and year to date accu- 
mulative AUU totals. 

product name (ISFNAME) - A literal, one to 10 characters 
in length, used to designate the software product's name. 

software code (ISCODE) - A one- to four- character literal 
used as the software code to designate a particular job 
step within a vendor product. 

summary run - RANDR run used to generate utilization 
reports of usage priced applications for the past six months 
up to the current date, 

update run (id=l) - RANDR run used to build and maintain 
the product fUe. An update is either specified by a para- 
meter card or implied with address or pixjduct cards 
(ld=2, 3 or 4). 

update report - Report generated by RANDR as a result of 
an update listing all the cards processed durli^ the update 
run and the disposition of each operation. 
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usage detail report - Report produced as a result of a vendor code since the last billing run was made and up 

billing or summary run listing each individual run detail to a six montii history, 
record by software code within product by vendor code. 

vendor code (TVENCD) - A two-character literal used to 

usage summary report - Report produced as a result of a indicate the vendor of the application. Vendor codes CD, 

billing or summary run listing the total liability ot usage 00 and W (t^pace) are reserved for Control Data's vse 

priced applications by software code within product by only. 
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EXAMPLE PROGRAMS 



B 



The following three sample programs Illustrate a method 
of calling ACOUNTX from FORTRAN Extended 4, COBOL 
4 and COMPASS 3. 

All three samples perform the following calls to ACOUNTX 
with the parameters specified: 

Call No. 1 - Start accounting with a rate of 3. 5 AUU/SS. 



Call No. 3 - Call ACOUNTX to determine the number of 
accumulated system seconds. 



ICODE = STAUU 
ISFNAME = SAMPLE 
KCODE = SAMP 
IRATE =3.5 
ISCHARG = Null 



- ACCOUNTX function. 

- Product name. 

- Software code. 

- AUU rate. 

- Surcharge. 



ICODE = LIMAUU 
ISFNAME = Null 
ISCODE =Null 
IRATE = Null 
ISCHARG = Null 
ISITEM = Null 



- ACOUNTX function. 

- Product name. 

- Software code. 

- AUU rate. 

- Surcharge. 

- Item code descriptor. 



ISITEM 


= blank 


- Item code description (not 
used). 


lALIM 


= Null 


- Limit. 


IVENCD 


= UU 


- Vendor code. 



lALIM = Any variable- Limit. 
Call No. 4 - Call ACOUNTX to end accounting. 

ICODE = EDAUU - ACOUNTX function. 



Call No. 2 - Change Rate to 2. AUU/SS and add a sur- 
charge of 10 units. The number of accumu- 
lated AUU's is returned in ISCHARG. 



ICODE = CRAUU 
ISFNAME = Null 
ISCODE = Null 
IRATE = 2. 
ISCHARG = 10 



- ACOUNTX function. 

- Product name. 

- Software code. 

- AUU rate. 

- Surcharge. 
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Example 1; FTNTEST 

FTNTEST is a sample program displaying the method of 
interfacing ACOtMTX from a FORTRAN-Extended (FTN 
I 4) program. 

1 PROGRAM FTNTEbt (OUTPyi) 

C THli pRoSRmm MAKES'PoUR CALLS fo ACoUNTx. 

C !• CALL ACOUNlX 15lSTAUU»6lSa"PLE.*LSaMH»150«0»*H .0»2HUU) 

C ^> CALL ACOUNTX (i>hCRAUU»U,a«c:0O i ) 0) 

b C 3l CALL ACOUNix (?LLIMAUUtO>U«0iO|Ot ISS) 

C 4» CALL ACOUNIX (SLEOAUUl 

C THli pHOGRam DISPLAYS THE METHUU OF CALl IWG ACOUNTX BY A 

C PROSraM SHitTEN' in tTN-4. 

DIMENSION" AHEa (6) tTAHL (35) 

10 DATA AKEA /IohnOW IS f"E,10H TIME 10 C.lOHOMt TO ThE.lQH AID OF YO 

c.ioHUH Country. loM / 

11 FORMAT (lOHlbCHAHG" »tl0.3) 
ea FORMAT (lOH SS = »fl0.3) 

J = r 

15 K=100 

C 

C MAKE STAKT CALL TO ACOUNTX. 
C SOFTWARt COUE = ^^MP 

C HROUUCT NAME « JaMPLE 

20 C AUU RSTt " « J.S 

C ITEM COut DES > JAMI 

C VENDOR CODE « yu 

C 

CALL ACOUNTX (5LSTAUUiOLSAMPLEt4LSAMPtr,50«n«»H ♦U.ZHUU) 
25 CALL PlLESQ(lAHLt3LLFN.<,LABCD;2L''o.2LSot2LRT.l| C,2lRT, lLit2LFL»60) 

CALL 0>'ENM (TAHL.6L0Ut>:uT) 
C WASIE A LitTLE 1Im£ TO BUILD Uh AUUS 
00 lo'i = JVK 
CALL PUT(TABL.AREA«60) 
30 10 CONTINUE 

C SET Up TO laLL ACOUimx wiTM a kaTE cHANrsE TO 2.0 AUU/SS 

C AND ADD A SUHCHARv?t OF 10. 

C 

ISChARti m 10 
35 CALL ACOUNTX t5HCRAuU»U . i2oOt ISCMARai 

C 

C ISChARG NO* CONJAINS THE NUMflEH OF a^US CONSUMED DURING THIS 
C PORTION o(= FTNTE!»i. 

C ISCHarG - mhR AUU * 1000. SO* UiVIOE BY lOOn. 
40 C PRINT ISCmARQ* 

C 

CHARG = ISCHAkg / lOOUi 
PRINT 11. CHAhg 
C 
45 C RESET ISCHahG TO Zt«0 SO AN INaoVERTANT CALI TO ACOUNTX WHICH 

C SOUlU ADu a SURCHahGE to The aUOS. THF SURCHARGt WILL BE 0, 

C 
C 

C WAJ>It MORE TIME TO «CCUHULATE MURE dUUS. 
50 C 

DO 20 1 3 li2u 
CALL PUT (TA8l,AREA,60) 
HI CONTINUE 
C 
55 C MAKE CALL lO ACOuNIA TO OBTAIN (HE nUMBfh OF SYSTEM SECONDS 

c consumeo Thus far." 

C 

ISS » 50 

CALL ALOUNTX IfeLLlMAUU • UfO»0»U "O' l^S) 
60 C — 

C ISS CONTAIiNS THE NUMbER OF Ss CONSUMED » lOnO. So DIVIDE BY 
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bg C 1U00> 

C ' 

SS = ISS /lOOU. 
PRINT 22, S| 
C 
70 C NOW WE CAN cOASI aUU TME WAY lo OOR END CALI . !-tT*S ACCUMULATE 

C MURE AUUs. 

C 

DO 30 i s l*2u 

CALL PUT (TABL,AHtA,60', 
7S 30 CONTINUE 

C 

C ' WE ARE NOT fiOINfa TO SUHCHA^O TniS EnO CALL «;0 Wt OON*I HAVE 

C TO mAkLsuRE THAI iSCMARti I5 sEI TO THfe VALuE *£ wANT TO 

C SURchAfGt THE RUS» BUT I^ Wfc uID mE WoULlI SfT iScHARG TO 

80 C THE PROPtH vALUEi SAY 20» AND CAl|_ ACoUKTX BY THE FOLLOwINSs 

C ' ISChaRG = 2>J 

C CALL AcOUNT* (5LEDAUU,0,O,0»tSCHAHU) 

C BUT WE wiLu MAKE OUk CaLL wITHooT IsCHArG. 

c " ■ 

ag CALL AtOUNTX (SLEUAUU). 

C 

C • TIME TO CLUSE THE t.fLE AND 00 HOME. 

C " " 

CALL CLOsbM (IaBD 
90 END 



00«13.l9.FTNo02M" FROM 

00Tl3.19".iP 00000576 WORDS - ULE INPUT ♦ DC ;U 

06»13.i9ieTN,CM50000, r«>o. 

00.i3.19.FTN. 

Uil'Xa.^i .S09 CH SECONDS COmPILAiiON TlMt 

00113. 23;;L(>0. 

66Ti3.30i SWCS UU SAMP SAMPLE 

0U<13.3d< SWCE UU SAMP AUUS USED s lO'^^^l 

OoIlS.aoI «uUS ACCUMULATED = lO.*!?* 

6ull3,3l« END FlNJEST 

00.13.3l. .l(>l^ CP SECONDS tXECUTIuN TIME 

6o»13.3liOP 00005440 WORDS - FILE OUTPUT . OC 4y 

00I13.31;mS 7I68 wURDS ( ' maX USED) 

00<13.3UCPA 5<<!66 SEC. 5.<:(i6 AUJ. 

007l3.3l.IO 1.IU9 SEC. 1.109 AUJ. 

00^13. 31.CM 130. 4nd KWS. 7.1IS9 AUJ. 

00713. 31.SS 14.J35 

00^13. 3liPP ft.bbl SEC. 

00;i3,3l.tJ END OF JOb. ♦» 



HN002M //// ENO UF LIST /<// 
l-INOOZM //// EnO of list //// 
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Example 2: COBTEST 

COBTEST Is a sample program displaying the method of 
interfacing ACOUNTX from a COBOL 4 program. 



UUOOi 
uooo<: 

00003 
0000^ 

6000& 
6ooo(> 

00007 

oooot* 

OOOO'' 
UOOIU 
00011 
ObOli! 
0601^ 
(>001<» 
OoOlb 
00016 
00017 
OOOIU 
00019 
UO02O 
00021 
0002^ 
00023 
0U02'» 
0002b 
00026 
00027 
6602B 
0002<« 
00030 
00031 
0003<: 
0O033 
60U3<» 
O003b 
U0036 
00037 
U003U 
00O34 
0004U 
0OO41 
0004^ 
0004J 
00044 
0004i> 
00046 
00047 
00046 
0004V 
0005U 
OOOSl 
0005^ 
00053 
00054 

6 005b 
00056 
0005' 
00056 
OOOS""! 
0006U 



IDEMIFICATIUN OlVISlyh. 
PkOGftAM-il), COBTtSl. 
AUTHOR, cue' 
INSTALLAIiON. 
bATE-«RIITEN. 

'StPTEMBEH ?t l'i75? 
» RtMAKKS. 

» "' -THIS PROGRAM XILL 8t* OStlA 10 SIMiiLATf A ^JSeR PROGRAM 
» USInO pAHAMtitRS nE|-UEU io FijNCTtON aCOUNU IN A COBOL 

» ENViRONMENTl* 

» -FOUh calls WfLL 6E MADt 10 ACOUNTX 
» ' One Sf^UU "ITU IHaIE EoUAL TU :i.5 

» T(»() CKAyu WITH IHaIE EqUAl TO 7 ANO 1SCHAR6 = 10 

» Three Li"UU To SETnumBEp OF S6 IISeO 

• FuuR EUAUU WITH NO OTHER PARAMETERS. 

» -THIS PROGRAM UISPLAVS }nx. METHOD Of rALUlNCi ACOUNTX et 
» a'Cohol PR0<>«aM. 
ENVIRONMENT UIVISION' 
CONFibORATlON SECI ION. 

sourCI-comMoier. 

6oo0. 

OBJECI-COMPUIER. 

6uoO. 

input-output section. 
file-<-onTr6l. 

SELECT CAHOS assign 10 InpuT, 
DATA UlVlSlOn. 
WORKIN6-STOR«GE SECTiUN. 
01 ICOUE 



01 
01 
01 
01 
Ul 
01 
01 
01 
01 



usagl 

USA6§ 



COMH-i 
COMH-I 



USAGt IS ComH-1 



USAGt iS COMK-i 



X(10) 

X(10) 

X(10) 

9(10> 

9(10) 

X(10> 

KlC 9(10) 

HlC X(10) 

KlC 9(10) 

KIC 9(10) 



HlC 
KIC 
KlC 
f IC 
PiC 

MIC 



W«LtlE 
VALUE 
V»>LuE 
VALUE 
VAldE 
VALUE 
««Lt)E 
VALUE 
VALUE 



*STauu*« 

^SAMPLE*. 

#bAMp^, 

360. 

10. 

* *' 

ZEHoS. 

ZEK.)S. 



iSFNAnt 

ISCbOt 

IRATE 

iSChAhG 
ISITEm 

iAlIm 
iveNcu 

COUNT-A 
II 
PROCtUURE UI»ISION. 

FUNCTION-SIAht. „ ,v „ ^ 

EnTEk FORIRAN-A ACOUiflX UbING ICOnF» TSFNAMt. ISCODE. 

IHAtt. 1SChA«6» iSIltMi lALlM. lutNCn. 
Ptt'FoHM TlME-^UUT THKU liME-ExIT WAHYTNG H FROM I BY 1 
UNTIL II GRtAlEH THAW bouO. 
FUNCl lON-CHAivGE-HATE. 

MOVE «CRAUU* '0 ICODt. 

MOVE 200 10 1«A1E. 

EnTem FOHIRAN-X ACOUfMiX USING ICOnt' TSfNAMe, ISCODE. 

IKAlt. iSCHAKy. 
PEKFuHM tlME-«OUl THRU UmE-ExIT VAHYTNG ii FROM 1 BY 1 
UNTiL li GRt«I£R THAIM buoOO. 
FUNCllON-CHAiNCiE-LlMlf . 

MOVE »LiMAuu* ro ICOUt. 

MOVE /EROS TO lALlM. 

ENTEm FORIHA'^-X ACOUINIX UbUG ICOnfc. tSFNAMl. ISCODE. 
IHAlt. lSCHA«Gf ISIlt-Mf lALlM. 

funciion-end-accountI'«g. 

PtHfUHM llMe-«OUl TH«U llmE-EXiT vAhYiNG i» FROM 1 BY 1 

UNTiL li GRt«IEH THAN 7t)OO0. 
MOVE *EDAOU*"j.O ICOOL. 
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00061 MOVE ZERO TO .fSCHARG. 

00062 MOVE «EDAHU# |U ICQOi* 

00063 LNTEm FORTraN-X ACOUNlX USING ICOnfe' TSpNAMe, IScODEi 

00064 IRAit, iSCHAKQ, IsITEh* iALlu. 

00066 TIME-HOUT," 

06066 ' Ado I TO couni-a. 

00067 TIME-tXlt; 

Od06tt " MOVE ZERO TO ^OUNT-A. 

0006'* END-PHOOHAM. 

00070 STOP HUN« 

Otl.I2.49.CoBTb2K FRUM 

U««12.49.IP 00000640 "ORDS - MLE INPuT f OC vo 

0a7t2.49.CoBTESTiCM6bO00>T2U0. 

UU«12>4V^C0B0L. 

00712. Sl.COMPiLiNG CUhIEST 

U0.12.557~000 E AND T/U DIAGNOSTICS ISSUEU 

00712.557 0544008 bCM USED 

6u7i2,55. .924 «,K~SECONDS tOMPILAIiON ]IMt 

007l2.55.£NL) COBOL 

007l2.5biMAP,OFF. 

067l2.56.LGO. 

u67l3.o2« SWCS UU bAMP SAMPLE 

Ou7l3.l&7 SWtE UU SAMP AUUS UStO = 66. ''34 

00713.157 AuUS ACCUMULATED = b6.^?* 

6u7l3.16;0P 0000121b *ORDS - flLEOUTcuT i OC 4u 

007l3. 167ms 3584 kOROS ( MAX USED) 

U0«13.16;CPA 13.Ji9 SEC. l3.Ji9 ADJ. 

00713. 16. 10 l.<;2i SEC. I. £21 AUJ. 

0(t*13«16«CM 226>«3o KWS. I3<a44 AOj, 

007l3.l6.SS 28.JH5 

0U7l3,167PP 9.10' SEC. DATE u«/Dl/75 

O07l3.i67tj END OF JO?, •♦ 



84000440 B ^^ 



Example 3: CMPTEST 

CMPTEST is a sample program displaying the method of 
Interfacing ACOUNTX from a COMPASS 3 program. 






031S20«;«05232* 


TR*LE 


VFU 


*2/(hCmpTEST 




0011022 * 




VFU 


iB/oESlM 


1 


0O0UOuuUi<O0UOU0U0ui2 « 


# 
P«HAOU 


VFU 


«,U/lCCDF 


z 


avoaouuOaooooooui>ui3 * 




VFU 


60/lSFN»ME 


3 


OUOOOUI)30UOOOV000014 * 




VFU 


6C/1SC00E 


4 


ooooouu^ooooooouiiuis * 




VFU 


6U/iRATF 


5 


aooaauutJoouoooo(iOoi6 * 




vfo 


6U/1SCH6RG 


6 


ooooouuOuouoooouuoiT ♦ 




VFd 


6U/1S1TFM 


7 


ooooouuooouotjoooiiozu « 




VFD 


60/iALlM 


lu 


OOUOOuilCuOOOOOOUOOZl * 




VFU 


6U/lVENrD 


11 


■ 1 




BSSZ 


1 






* 

« 


PAkAMtIEK »REA. 


12 


23240 1£!3250000UUUOOO 


ICOUE 


VFU 


6ll/3LST«UU 


13 


23ollb<!~14u5aoo6uoOU 


ISFIMAMt 


VFU 


6i;/oLSamPLE 


1<| 


23uilb<;vOU0OOOuuu00O 


iscoot" 


vfo 


6U/»lSAmP 


15 


OOOOOVU^OOUaOOOUtlbjb 


IRAIE 


OATA 


3buu 


16 


ooooooutiiiooooooooooa 


ISCfl4«b 


DATA 





17 


S5S5Sbb?0O00U0a6600O 


ISllEM 


VFU 


60/»L 


2u 


oooaobuuOoooooouiioou 


lALlM 


OATA 





21 


2925ouv>*uouoaooi)oaoo 


IVENCU 


VFO 


bll/cLUU 



IUEnT C'lHIEST 
ENTRY BtlilH 
EXT aCouNTX 

THIS Hf*0<'HMM OtSPLAYS « m£1"oO OF CALLING ACOll'^TX BY A 
PHOBRAM »HiTTEM IN CUMPASS'vtHSlUN 3. 

PAHAMtJEH mOUrfSS hi UCk. It-HMINATEU HY A KORD OF ?tKU>5 



FllNCTlOw 
PPODUI.T NAMM 

snFTKAKe cuUe 

AUU RA't / SYSTEM SECOND 
SIIRChARuE 

ttem coac utscRiPTOR 

LlMjT, RETURN OF ACCuM S*. 

VFNoOh CODE 

irao TtHMINATOR FOR HARAMtTEH AUUh | ,ST 



22 BEGIN 



22 SllOOuotlul * 

23 oiooouuoao X 

" 0023 ♦ 

000000 



24 6110001)001 

" 612001/777 

25 67221 CWP.I 

0b2a000025 • 

26 716a00U>'12 

717O0OU310 

27 5120000051 ♦ 

■ SlbOOOOOlb ♦ 

30 5170000015 * 

" 10622 

31 5110000001 ♦ 

S16000II012 ♦ 

32 OlOOOOOUOO X ' * 

■ 0032 ♦ 

000000 * 



BSS 

MAKE STAHl CALL 

SAl PAhmDU <nlv s AUUR OF pARAM AUDR ULqCk 

HJ ALounTX SIAPT ACCUUnTING 

VFU li/«il8/THArt (IRaCE XOHO ♦ LINE nU"BEH) 

HASTE SOWt TlMF TO AtCllMULAIt AUUS. 



SUl 

SU2 

Sb2 

NE 

SXb 

SX7 

SA2 

SA6 

SA7 

BX6 

SAl 

SAb 

RJ 

VFU 



1 

11 1 na 

B2-BI 

B2<cO)CmP. 

luu 

200U 

shsuRAUllo 

iStnAHG 

IHaIE 

X2 

PAKmOO 

iCouE 

Ai'UUNTX 

l2/«,18/TRArt 



StrilP FOR CALL TO CHANGE RAiE 

NtW RATt = 2.0 

CHANGE FUNCTION TO CHANGE R^TE 

StT SURC'*<»RGE IN ISCHARG PAKiNtTtR 

StT NEW Rate' IN IRATE 

StT CRAUU IN ICODE 

(All 3 AUuR OF PARAM AODR BLqCK 

CHANGE t<ATE 

(LINE NbR ♦ TRACE WORw) 



B-6 



84000440 B 



33 612000/777 

34 67221 CMP. 5 

Obit000003't ♦ 



35 71600UO106 

5120aUUU52 

36 10722 

b|6000U020 ♦ 

37 Si700uri012 ♦ 

SllOUOOOOl 
lU OlOOQlloUUO X 

0040 ♦ 

OUOOOU 



41 43700 

Oli0017777 

42 67221 CMP. 11.1 

Ubi:0000042 ♦ 

43 51700unU20 ♦ 



512000U053 ♦ 

44 S1700lM(U02 ♦ 

" 10722 

45 51700U11U12 ♦ 

" 5110000001 ♦ 

46 OlOOOouOOO X 

0046 ♦ 

OUOUQO * 



47 716024/021 
S4 



UO 
Oo 
UU 
OU 
00 
bit 

iit 
oil 

oil 
Itii 

OU 
00 
OU 

oil 
00 

iiit 
00 

OU 



TMt ELtMtNl 
UPON HtTUKN 
SET TO Tf^t 
CHANGt RAlt 
IT IS NOT 
ISCHAKG «S 
VALUE fRUM 
THIS VAtUt 
THE CALLt-H. 
WEHY KAPiuL 



ISCHARfl »I|L CONTAIN THE NUMBER Of «UU • U)nn 

FRnM The CHANGE RATE CALL. ISCHaWI? MUST BE 
NEW SURrHBHBE RATE iF SUBSEQUENT CALL TO 

OR END I*ITH liCHARO SPECIFIED) A*"- MADE. TF 
ESEt And a call T.) ACOunTX is made "HIGH SKtriFIES 
A RfQUIrfu nR OPflONAL PARAMETER^ Tnp He TURnfo 
THE PREVIOUS CALL WILL BE USER AS THE SUHCHApfiP. 
IS MULTrHLlFO 8T 1000 BEFORE IT IS'«ETURNtU TO 

SO THAT WOULO BE A OOOD WAY TO ACCUMULATt CHAoSEs 
Y. WE WILI CLEAR ISCHARG NOW SO Wt DON* I ^nRR6T. 

WASTE MOi<fc T'ME TO BUILD UP ALUS ano«sT 



SB2 77//B 

Sb2 B2-al 

NE 8«!tO0«CMP.5 

lALIM WAi i-HANrEU FHUM 50 10 a NtW VALUEt THE NUMRtH 

OF SS ACCUMULATED BY ThE SfAHU CA(.L SO lALIM MU.;T 

BE CHANetu TO THE NE* VALUE OF SS LIMIT. 



IhLiM so WO fcWROR OCCURS. SC-T PAHam i leT An 
M»KF LImII call 



UPON HETUhw, the El f.MENT lALlM WILL CONTAIN THt \UMBtK nF 
SYSTEM SttUNDS ACCUMULATED JnUS tAR. IT IS A ^OOU PHACTIct 
TO CLtAp' IHIS FLEmFNI ftFTER IT IS NOT NEEDED. 



SX6 


7uu 


SA2 


sH'LIMAllU* 


BX? 


X2 


SA6 


lALlM 


SA7 


ICuuiE 


SAl 


PAHMDD 


HJ 


ACooNIX 


VFU 


12/*.18/TR 



MX7 





SB2 


lUne WASTE MORt 


SB2 


82-01 


NE 


B2.oo»CMP,ln 


SA7 


IALIM HtSFT lALlM 



THEN MAKE FND CALL. 



SETUP 10 EimD AijU SroUNTING. OUR CALL WILL CONSIST 01- 
JUST IHE H.O0E PARiMtTFR NOl THE ISCHaRG PARAMETER AS "Ft I . 
THUS WE StI THf ADOhESS L^Sl TERMINATOR IMMEDIATELY fOlinriNG 
THE ICODt fAfiAMETER IN THE AuDRtSS LIST. 



GtT PARAMETER ADDR LIST ADDRESS. 
M»KF ENO call 



WE ARE FlNlShEnt YnlJ CAN 60 HOME NOW. 

ENURUW 

END BEtolN 



SA2 


sHHttDAuu» 


SAT 


PAh«DU*i 


8X7 


Xii 


SA7 


ICouE 


SAl 


PAHMOO 


HJ 


ALUUNIX 


VFD 


12/*.18/T 



•l3,0l.CHPTE2L FROM 

^la.OlilP U000076B WORDS - FILE INPur t DC iO 

•13,nl.CHPTfcSTiCM5un00«T20. 
i7l3, 02. COMPASS. 

Jl3.05i'ASStMBLY COmHLETE. 464008 CM USED. 

713.05. 1.832 LRU SECONDS ASSEMBLY TIME^ 

.13.06.L60. 

;13.i2; SWCS UU SAMP 
l.l3.i2V SWCE UU SAMP 

•13.127 

• 13. 12. OP 00004352 "ORDS - ULE OUTfuT f DC 4u 
7168 



ri3,l2.MS 
ul3.i2.CPA 
7l3,12;io 
.13.12;CM 

'is.uiss 

13,13;PP 

i3.i3;tj 



SAMPLE 

AUUS USED a: lo.u'O 

AUUS ACCUMULATED = lO.O'o 

00004352 «ORDS - flLEOUTfuT 



■nOROS ( 
4.bbi> SEC. 
.627 SEC. 
10S.>«b8 KWS. 

4. /OB SEC. 
END OF JUBt •» 



6 MAX USED) 

4.US5 AUJ. 

.o?? ftUJ, 

b.tbS AUJ. 

11.052 

DATE UH/ol/75 
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CPU MODEL CODES 



Upon creation of the product file, the parameter card 
(id=l) must be specified with UPDATE as the run type and 
a matshine code (CPU model code). The appropriate code 
is to be chosen from the table below: 

Machine Code 



Machine 


6200 


6400 


6500 


6600 


6700 


CYBER 71 


CYBER 72 


CYBER 73 


CYBER 74 


CYBER 171 



CY62 
CY64 
CY65 
CY66 
CY67 
CY71 
CY72 
CY73 
CY74 
C171 



Machine 

CYBER 172 
CYBER 173 
CYBER 174 
CYBER 175 
CYBER 175-1 
CYBER 175-2 
CYBER 175-3 
CYBER 176 



Machine Code 

C172 
C173 
C174 
C175 
L175 
C175 
U175 
C176 



The customer Is obligated, in the event of a CPU model 
upgrade, [for example, a CYBER 172 (C172) with a 
10316-1 upgrade is a CYBER 173 (C173)], to perform a 
final billing run on existing product and usage detail files, 
remove those files and recreate them with the appropriate 
CPU model code. 
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COMMENT SHEET 

MANUAL TITLE Usage Accounting Utility Reference Manual 



PUBLICATION NO 84000440 REVISION . 



FROM: name:. 



business 
address:. 



COMMENTS: 

This form is not intended to be used as an order blank. Your evaluation of this manual will be welcomed 
by Control Data Corporation. Any errors, suggested additions or deletions, or general comments may 
be made below. Please include page number references and fill in publication revision level as shown by 
the last entry on the Record of Revision page at the front of the manual. Customer engineers are urged 
to use the TAR. 
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